Securables are the entities in SQL Server on which
permissions can be granted. In other words, principals (for example,
users or logins) obtain permission to securables. This article
describes many examples of securables, including tables, databases, and
many entities
that have been part of the SQL Server security model in past versions.
SQL Server 2008’s security model contains a granular set of securables
for applying permissions.
Securables are hierarchical
in nature and are broken down into nested hierarchies of named scopes.
Three scopes are defined: at the server, database, and schema levels. Table 1 list the securables for each scope.
Table 1. SQL Server 2008 Securables
| Server | Database | Schema |
|---|
| Logins | User | Table |
| Endpoints | Role | View |
| Databases | Application role | Function |
| | Assembly | Procedure |
| | Message Type | Queue |
| | Route | Type |
| | Service | Synonym |
| | Remote Service Binding | Aggregate |
| | Fulltext Catalog | XML Schema Collection |
| | | Certificate |
| | Asymmetric Key | |
| | Symmetric Key | |
| | Contract | |
| | Schema | |
As mentioned earlier, a
hierarchy exists within each scope; in addition, relationships cross
scope boundaries. Servers contain databases, databases contain schemas,
and schemas contain a myriad of objects that are also hierarchical.
When certain permissions are granted on a securable at the server level
the permissions cascade; meaning permission is granted at the database
and schema levels. For example, if a login is granted control permission at the server level, control
is implicitly granted at the database and schema levels. The
relationships between securables and permissions can be complicated.
The next section details the different types of permissions and sheds
some light on how these permissions affect securables.
